业务团队如何在日常工作中做稳定性？涵盖事前、事中、事后的方方面面 | 原创

这是Bella酱的第 141 期分享

作者 |Bella酱

你好呀，我是Bella酱～

“又不是不能用，能用就行。”“又不是不能跑，能跑就行。程序和人有一个能跑就行。”

相信很多同学都听过这2句话。乍听没毛病。编程3部曲，“make it run，make it fast，make it better”。上述2句话，我将其归结为“make it run”这一个阶段，单看这一阶段，没有问题，但是若始终在这一阶段，那就有问题了。

什么是稳定性呢？我将其归类到“make it better”这个阶段。稳定性是通过一系列手段提前发现问题，力求将问题扼杀在襁褓中；稳定性要求在问题发生时，先于业务感知问题，处理问题，进而将问题影响面降至最小；稳定性要求问题发生后要有复盘，复盘哪里可以改进，以避免再次发生此类事情。简言之，稳定性就是为了保障系统正常运行，保障业务如丝般顺滑，保障数据准确无误。

稳定性并非只能够做一些零零散散的事情，稳定性也是有章可循的，有体系化的方法的。本文将从机制管控、监控告警、梳理系统风险点、保命措施、线上问题应急机制、故障演练、事后复盘、宣讲这8个方面来讲解业务团队如果在日常工作中做稳定性，可谓是涵盖了事前、事中、事后的方方面面。

1.机制管控

所有事情，能上系统就上系统，靠人来运转风险是极高的。这个道理，我相信很多同学都是明白的。稳定性保障亦是如此，通过一系列机制和系统强管控来规范日常工作中的一些行为。

下面这些都是可以参考的：

1）分支发布必须merge origin master分支的代码。

2）分支发布必须cr，且必须通过测试人员同意才可发布。开发、测试不可为同一人，除非测试认可开发自测即可。发布人员和cr人员不可为同一人。

3）分支发布需要在系统中有记录，内容至少包含发布时间、发布分支、发布内容、影响面、是否测试通过等等。

4）制定发布窗口，窗口外的时间如果需要发布，则需要走审批，审批人员可以是老板，也可以是团队内负责稳定性工作的人员，也可以视团队情况设置为其他的人员，例如团队核心开发等。制定发布窗口主要是为了防止晚上或周末发布的情况，避免发布出现问题时响应和处理不及时。

5）制定发布流程，主要是服务器环境这方面的，例如发布系统设置分支必须先在日常环境部署成功，才能部署预发；只有预发环境部署成功，才能部署线上；发布线上时，必须先在beta环境部署成功，且观察规定时间内，才能继续发布至线上；线上至少分几批来发布，每一批至少观察多久等等。

6）禁止流量一刀切，必须有逐步灰度的过程。通过发布机器的占比也好，通过业务中带灰度标的方式也好，必须要逐步灰度，禁止流量一次性全部切换。逐步灰度的过程是一个验证功能，暴露问题的过程，灰度范围是可控的，可以将灰度范围告知业务方，以便出现问题时，业务方知道哪里有了问题，而不是摸不着头脑。

7）数据修复必须通过工具来操作，工具要可获取当前操作人员，操作时间等，工具要具备check数据修复正确性的能力，工具的每次使用要在后台有记录，方便以后查看历史操作记录。

2.监控告警

监控告警的意义在于先于业务方发现问题，可以极大的提高响应速度，更快的开始定位问题。问题一旦定位到，影响面也就可以评估出来了，此时应该考虑如何快速止血，将影响面降至最低。

监控告警设置时有以下几点需要注意：

1）告警范围。切忌只告警给某个人，这样风险太大，例如当这个人在洗漱时就可能会错过告警信息。可以建一个钉钉告警群，把和这个业务相关的同学都拉进去，以及团队内负责稳定性的同学、老板等等。这样避免了“单点不可用造成服务宕机的情况”，即使一个人错过了告警信息，还有其他人，只要有人看到报警信息并处理就ok。

2）告警优先级。不同情况需要设置不同的告警优先级。举一个简单的例子，以服务成功率来说，持续3分钟成功率低于97%，可以告警至钉钉告警群；持续5分钟成功率低于97%，可以短信告警至订阅人；持续10分钟成功率低于97%，可以直接电话订阅人。

3）告警内容。这个需要视团队服务现状而定。一般来说，DB层面的监控告警、服务成功率层面的监控告警、服务处理失败数的监控告警、机器层面的监控告警等是必须的。DB监控告警例如CPU使用率、连接数、QPS、TPS、RT、磁盘使用率等。机器层面的监控告警例如CPU使用率、load、磁盘利用率等。服务成功率的告警配置时需要考虑持续时长。

4）告警有限性验证。这点是非常关键的，如果告警无效，那上述告警范围、优先级、内容这3个工作就是徒劳的。如果告警设置的阈值太高，那告警将起不到任何作用。如果告警设置的阈值太低，那每天都会接受到大量的告警，久而久之，就对这些告警疲倦了，等哪天狼真的来了，人们可能已经不相信了。经过压测，摸清了服务、DB、机器等的基线后，根据基线设置的告警是最可信的。若前期没有压测，可以先观察一下日常的水位，将告警阈值设置低一些，后面再根据告警情况慢慢调整告警的阈值。

3.梳理系统风险点

古人云，知己知彼，百战不殆。为何要知彼呢？知彼，你才知道他的弱点。做稳定性亦是如此。了解系统，你才会知道系统的风险点在哪里。当然，完全了解一个系统，是需要投入大量的时间和精力的。古人又云，君子性非异也，善假于物也。那梳理系统风险点的前期，你可以借一下你可爱的同事们的力呀～找到对应应用的owner，了解一下现状，以及潜在的风险点，以及是否有应对措施。

在梳理系统风险点时，需要关注以下几点：

1）链路是否闭环。这点是非常关键的，因为如果是系统层面的缺陷，那影响面一定是很大的。梳理链路是否闭环时，需要你跳出开发的思维，以审视一个产品的角度来考虑，这个产品是否可以在任何情况下正常的run起来。如果发现系统不闭环，一定要第一时间告知产品和老板。然后再从产品的角度来考虑如何解决这个问题，需要开发什么功能才ok，然后再将此作为高优先级的开发任务去进行排期修复。

2）慢SQL。慢SQL的威力是非常大的，一条慢SQL的执行可能会直接拖垮一个库，此时如果再有其他SQL请求执行，那其他SQL的执行耗时也会放大很多，这个时候，对于开发人员来说往往难以分辨哪些才是真正的慢SQL。此时需要静下心来根据时间点来慢慢查找真正的慢SQL，或者求助DBA同学，专业的同学做专业的事情，结果会更可靠，耗时也更短一些。如果是自己找到了慢SQL，最好和DBA同学求证一下自己查找的结果是否正确，以免错过了真正的慢SQL。

3）核心应用、非核心应用是否互相影响。不同重要等级的业务，应该在物理维度直接隔离。常说的读写分离也是这个道理，读写请求分别访问不同的机器组，以免互相影响。除此之外，还有DB维度的分离。

4.保命措施

机制管控、监控告警、梳理系统风险点都是为了防止问题的发生。可是，常在河边走哪有不湿鞋？如果线上发生了问题，要怎么快速止血呢？这个时候，就需要日常工作中准备好一些保命措施了，如果等到问题发生时，再去做准备，就有点太晚了。

那有哪些保命措施呢？

1）限流。虽然限流会导致一部分请求失败，但是他会减轻服务压力，减轻DB压力呀，在有些时候是可以用来保命的。常用的限流工具有Sentinel。日常工作中，可以先在Sentinel控制台配置好限流值，问题发生时，直接推限流开关即可。可以针对集群限流，也可以对单机配置限流，这个要看具体的业务场景和需求了。可以对所有应用来源进行限流，也可以对某些特定应用配置限流值，这个也是看具体的需求了。

2）降级。降级分为有损降级和无损降级。有损降级是业务感知的，无损降级只是技术侧的，例如查询从一个数据源降级为另外一个备用数据源，业务侧毫无感知。有损降级，比较典型的例子就是春晚抢红包活动，百度直接公告通知除夕当晚，百度云盘登录注册降级，以保障春晚抢红包活动顺利进行。对于有损降级来说，要在日常工作中就定义好，何种情况下，系统达到什么指标了，才可以进行有损降级。以免问题发生时，考虑过少，直接降级，导致更严重的问题发生。

3）切流。当一个机房的服务器发生了网络问题或硬件设施问题或其他导致机房不可用的问题时，可以切流至其他机房。当一个数据源不可用时，也可以切流至备用数据源。这些都可以减小问题的影响面，或解决问题。

4）布控。如果是和外部用户打交道的服务出现了问题，可以通过业务方或其他方式通知外部用户，告诉他们此时系统发生了问题，相关同学正在解决中，以安抚他们，而不至于让外部用户一脸懵逼，不知所措。一些官方号通过发微博的方式告知用户，也是布控的一种。

5）上下游、DBA等的联系方式。有时候可能并非自己系统的问题，而是上下游系统异常，间接导致自己系统的成功率下跌，这个时候，掌握上下游合作方同学的联系方式就很重要了，可以快速通知对方，让对方介入排查。有时候也可能是DB发生了问题，需要DBA协助解决才行，所以掌握DBA的联系方式也是非常重要的，DBA同学一个小小的命令可能就能拯救你于水火之中。

限流、降级、切流、布控等保命措施均需要清晰的定义系统哪些指标达到什么值时，才可以执行这些措施。这样当问题发生时，可以快速做出决策判断，也避免了使用不当造成更大问题。

5.线上问题应急机制

真的有线上问题发生了，怎么办？莫慌，越慌越乱。

首先，需要做到快速响应，表明已经有人在定位问题了。问题定位到之后，应该将如何快速止血放在第一位。此时就可以将上述的保命措施用上了。如果保命措施都用不到怎么办？只能采取其他措施了，通过发布解决也是一种方式。

一个人是无法很好的快速应急的。需要有通讯员和外部沟通，及时汇报当前进展；需要有处理人定位问题，评估影响面，给出建议；需要有决策人员，可能是团队内稳定性负责人，可能是老板、也可能是业务方等，决策如何快速止血。达成一致决策后，处理人按照决策执行即可，通讯员保持和外部及时的沟通。

6.故障演练

故障演练的目的是模拟故障发生时，大家的真实反应，以及是如何处理问题的。所以故障演练不要提前告知团队同学，更不要提前告知是何种线上问题，否则演练将毫无意义。当然，故障演练还应该把握好度，以免影响到线上业务。

7.事后复盘

线上问题发生后，无论大小，都应该有相应的复盘，小问题可以是小范围的复盘，大问题可以进一步扩大复盘参与人员的范围。

主要复盘哪些内容呢？

1）何时发现问题？

确定时间点

2）哪种方式发现的问题？监控告警还是业务方反馈？

以确定监控告警是否有效，是否有可优化的空间。

3）何时响应问题？

以确定响应是否及时，是否有可优化空间

4）何时定位到问题？

以评估对系统的熟悉度，或对线上问题的响应处理能力。有的同学可能是因为对系统不够了解，所以需要耗时很久才能够定位到问题；有的同学可能是因为遇到事情时，或高压下，心理素质不够，导致手忙脚乱，所以才耗时比平时更久。两种情况，可提升的能力是不同的。

5）有无快速止血措施？

例如限流、降级、切流等。可看平时保障工作是否到位。如果发现有缺失，则可以记为一个action，后面工作中把这一块给补上。最好的方式是，同步梳理下，系统中是否还有其他缺失的快速止血措施，并一起做掉。

6）需要上下游或DBA介入的情况，协同是否顺畅？

以评估协同沟通是否有可提升的空间，毕竟需要上下游或DBA介入的情况，如果可以快速联系到对应同学的话，是可以节省很多时间的，有助于更快速的解决问题。

8.宣讲

稳定性从来都不是一个人的事情，它关系到每一位同学，也是每一位同学应该铭记于心的事情。

在接需求时，需要考虑需求是否合理，链路是否闭环。

在写代码时，需要考虑代码的健壮性，语法使用是否正确，是否在写慢SQL。

在发布时，需要考虑测试是否通过，是否在发布窗口期，是否有灰度策略，发布时若发现问题应如何处理，是否可回滚等等。

在线上问题发生时，如何快速应急也是每一位同学都应该了解的。

一些宣讲还是很有必要的，以帮助每一位同学更好的了解自己应该如何做以保障系统的稳定。

好啦，我是Bella酱，一个在BAT写代码的妹子，欢迎加我私人微信（微信号：linruLee_）一起学习一起成长！今天的分享就到这里，我们下期见～

-END-

更多精彩文章

更多系列文章请查看公众号底部菜单栏【系列文章】，快捷获取Java后端、计算机基础、系统架构、大数据、面试等系列文章~

如果你喜欢本文

请长按二维码，关注 Bella的技术轮子

转发至 朋友圈，是对我最大的支持

喜欢就点个在看吧